1. The Field of the Invention
The present invention relates to communication ports. More specifically, the present invention relates methods, systems, and computer program products for multiplexing a communication port to provide an additional independent communication channel.
2. Background and Related Art
Developing hardware and software for embedded system presents a variety of challenges. One challenge in particular relates to differences that frequently are encountered between the development environment and the runtime environment. As a general rule, development environments include a rich set of design tools, such as editors, compilers, debuggers, simulators, etc., to facilitate the development process, whereas runtime environments for embedded systems tend to be optimized for a particular specialized task. Often cost and efficiency drive the level of optimization of a runtime environment for an embedded system.
For example, consider the development of software and hardware for a cellular telephone. While the cellular telephone may include a display and a keyboard, it is far from an ideal development environment. To improve the cellular telephone as a development platform, a video card could be added for a larger display, a mouse port and a port for a full size keyboard could be added to simplify user input, the memory and internal processor could be enhanced to support a compiler, a debugger, and other development tools, and so forth. Of course, improving the cellular telephone as a development platform makes little sense because the increased size, performance, and cost will be wasted when the device is used as intended, and therefore will be of little or no benefit, and more likely a detriment, to the consumer who ultimately purchases a cellular telephone. Now, this is not to say the cellular telephone may not benefit from a larger display, additional input options, more memory, and increased processor performance. On the contrary, as cellular telephones become more general purpose computing devices, any and all of these enhancements are likely to occur. The point is that enhancements focusing on end use—on how the device is intended to operate day after day—provide more value to consumers than enhancements focusing on the development process.
Accordingly, it is usually desirable to minimize components that tend to serve only a development purpose and to maximize components that tend to provide a benefit for end use. For embedded system in particular, however, development specific components often are necessary. Since the runtime environment of an embedded system typically lacks sufficient development tools, the embedded system may communicate certain data to a more robust development environment for debugging and testing. The question then becomes how to communicate between the runtime environment and the development environment.
One approach is to provide a communication port that may be used for debugging within the embedded system. This communication port may be used by software engineers to develop and debug software related to the system, by hardware engineers to test specific parts of the system, and by the manufacturing team to test and debug the final product. The port also may be used when an end user returns a faulty product and the manufacturer needs to determine what went wrong. The system being developed often is referred to as a target system, and the system used for testing or debugging is often referred to as a host system.
There are many possible implementations for a communication port that is suitable for debugging and testing. The communication port may be a dedicated debugging and testing port. A dedicated port allows for complete testing of all target system components, except for the debugging port itself, but since the port is dedicated to debugging and testing, errors or malfunctions are unlikely to be detected by a consumer. A significant draw back to this approach, however, is the potential impact on the target system. Adding a dedicated port increases the cost of the target system by requiring additional components. Furthermore, design costs for the board may increase due to the additional components and signal lines or traces that must be laid out. In some circumstances, this may lead to a larger size than would otherwise be necessary, which may ripple throughout the target system—more power, larger enclosure, more cooling, etc.
To reduce costs, the components may be added only to a certain number of target systems that are used for testing and debugging. When the target system is produced, the components are omitted. Although some cost savings may be realized, omitting the components from production models introduces some new problems and continues to suffer from some old ones. For example, the real estates used by the components and signal lines in the testing and debugging systems may not be reclaimed in the production models because the components are simply omitted. Furthermore, having different production and testing models may be problematic because there is no testing of the system that consumers actually use. Moreover, when a defective target system is returned to the manufacturer, no testing may be performed to identify the cause of the problem until the omitted components are added to the system, which represents a fairly significant cost due to the specialized handling of a single system and a substantial loss of time.
Another option may be to run signal lines to the edge of a board where a connector may be attached. This solution also suffers from the problem of wasted space from having to route extra signal lines, and there is some cost associated with making the signals available at the edge of a board, either through a header or some other connector.
It is also possible to use an existing port for debugging and testing. While this approach may be appropriate for simple applications, it can be difficult to share a port. Typically, the shared port is not debugged because the shared port is the one communicating debugging and testing data, which prevents it from being monitored during normal operation. Another problem that this approach introduces is special software for using the shared port for debugging. As a result, software being debugged and tested is slightly different from the production software that will ultimately run on the target system. This introduces the possibility that latent bugs in the software will not be observed during testing and debugging, but will manifest themselves in the production software. Latent bugs of this sort can be extremely difficult to identify and correct.
Accordingly, methods, systems, and computer program products for multiplexing a communication port to provide an additional independent communication channel are desired.